Problems can be encountered during the execution of a software application. For example, exceptions to the normal operation of the software application can manifest in various ways, including, but not limited to, the following: irregular or undesirable results; erroneous data; interruptions to execution; poor performance; excessive and unnecessary resource utilization; abnormal or premature termination; abnormal state; and a complete failure of the application. The process of problem determination for such exceptions can involve the use of many tools and techniques. Perhaps most notably, the capture of information relating to the state of a software application at the point of exception can be utilized. For example, techniques such as First Failure Data Capture (FFDC) can provide an automated snapshot of a system environment when an unexpected internal error occurs. Furthermore, the provision of memory and state “dumps” can be relied on in the event of software failure and is common in such software as operating systems.
The inadequacies of such data capture techniques in problem determination are familiar to those skilled in the art, and include the limited scope of the data collected at the point of exception. For example, it is not possible to retrieve state information leading up to an exception using such techniques. To address these deficiencies, software tracing is often employed to monitor and record software application state information at execution time. In this way, a rich set of valuable trace information can be recorded for the entire execution of a software application such that, in the event of an exception, state information for the entire period leading up to the exception is available to assist in problem determination.
However, recording trace information routinely during the execution of a software application is burdensome and imposes a further resource requirement over and above that of the software application itself, manifesting as a requirement for further storage and processing throughput. In some environments, the burden of generating and recording trace information at execution time can be so great that it exceeds the resource requirements of the software application itself. For this reason, a decision to include facilities for the generation and recording of trace information in a software application typically involves a compromise. The balance is between a resource-efficient, high-performance software application and a rich set of trace information for use in the event of exceptions at runtime. Generally, though, regardless of how the balance is struck for a particular software application, performance and reliability are likely to be compromised.
It would therefore be advantageous to provide the advantages of a software application that is free of the burden of routinely generating and recording trace information at runtime, while also retaining the richness of trace data provided where such trace information is generated and recorded in the event of an exception.